r  .&****  ■  -. ^r-ry^* \ ,  —^t.jjV/.  „ 


/tfCURITY  CLASSIFICATION  OF  THIS  PAGE  (Whmt  Dmtm  Bnif4> 


REPORT  DOCUMENTATION  PAGE 


REPORT  NUMBER 


2.  GOVT  ACCESSION  NO. 

M'AirsJaL. 


4.  TITLE  (and  Subtitle) 


4 


(2  ELDON  WYNN Jg. 

^  5;  'perfonwinlui 


FACTORS  IN  MANAGEMENT  INFORMATION  SYSTEM JAILURES* 


7.  AUTHOR(A) 


'GARRISON 


7 


PgBPBWBigwiffiBWIiWBFiBwig  and  address 
Student, 

HQDA,  MILPERCEN  (DAPC-OPP-E) , 

200  Stovall  Street,  Alexandria,  VA  22332 


11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

HQPA, 

MILPERCEN,  ATTN «  DAPC-OPP-E 

200  Stovall  Street,  Alexandria,  VA  22332 


14.  MONITORING  AGENCY  NAME  ft  AOORESSfK  dlttoront  (ram  Controllhtd  Oltlce ) 


>  READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


S.  RECIPIENT'S  CATALOG  NUMBER 


REPORT  A  PERIOD  COVERED 

•INAL  REBKT  IS  Dec  80 


EPORT  NUMBER 


S.  CONTRACT  OR  GRANT  NUMBERfA) 


10.  PROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  *  WORK  UNIT  NUMBERS 


I*.  W»«»TniTt 


UNCLASSIFIED 


15a.  DECLASSI  FI  CATION/ DOWN  GRADING 
SCHEDULE 


16.  DISTRIBUTION  STATEMENT  (a!  thle  Report) 

Approved  for  public  release;  distribution  unlimited. 


17.  DISTRIBUTION  STATEMENT  (at  the  abstract  entered  la  Block  20,  II  dl  Iterant  from  Report) 


IB.  SUPPLEMENTARY  NOTES 

Professional  Report,  Graduate  School  of  Business,  University  of  Texas  at  Austin 


IS.  KEY  WORDS  (Continue  on  rarer  ee  aide  II  neceeeery  and  Identify  by  block  mrrnbor) 


Management  Information  System  failure 
Technology  / 

Communications  -V  i  _ 

Role  of  Top  Management  i 

MIS  Development  Cycle  - 


r. 


Monetary  Resources 
Cost/Benefit  Analysis 
Development  of  Knowledge 
Management  Integrated  Model  Infor¬ 
mation,  Capital  and  Control  System 


20.  ABSTRACT  fCaoOMu*  am  rereroe  aM»  ff  nmeeeeery  and  Identify  by  Mock  number) 

This  report  is  a  survey  of s current  literature  (1970  -  1980)  on  factors  that  can 
adversely  affect  the  successful  completion  and  execution  of  a  management  infor¬ 
mation  system  project.  Several  areas  are  examined,  includingi  (l)  technology, 
(2)  the  human  resource,  (3)  monetary  allocations,  and  (4)  the  development  of 
knowledge  during  the  project  life  cycle.  Some  of  the  problems  that  exist  arei 

(1)  mismanagement  of  technology  and  failing  to  understand  its  role  in  MIS,- 

(2)  inadequate  verbal  and  written  communication  skills,  (3)  insufficient  support 
and  involvement  on  the  part  of  top  management,  (4)  failure  to  have  a  definitive 


DO, 


JmTtI  1473  EDITION  OF  1  NOV  SB  IS  OBSOLETE 


\) 


5911  9  L  SECURITY  CLASSIFICATION  OF  THIS  PACE  fww«»  Dote  Kntered) 


Block  20 i  Abstract  con't 


and  specifications,  (6)  improper  use  of  personnel,  (7)  inability  to  quantify 
Intangible  costs  and  benefits,  (8)  inadequate  documentation  of  planning  and 
development  stages,  and  (9)  a  sqa^city  of  empirical  research  for  validating 
the  perceived  causes  of  failure  in  MIS  projects.  The  Management  Integrated 
Model  Information,  Capital  and  Control  System  (MIMIC^)  is  presented  as  an 
example  of  the  type  model  needed  for  successful  development  and  execution  of 
any  project  to  include  a  MIS. 


r\ 


80  12  19  10S 


FACTORS  IN  MANAGEMENT  INFORMATION  SYSTEM  FAILURES 


Eldon  Wynn  Garrison,  0-3 
HQDA,  MILPERCEN  (DAPC-OPP-E) 
200  Stovall  Street 
Alexandria,  VA  22332 


Final  report  December  8,  1980 


Approved  for  public  release;  distribution  unlimited. 


A  Professional  Report  submitted  to  the  Graduate  School 
of  Business,  The  University  of  Texas  at  Austin,  in  partial 
fulfillment  of  the  requirements  for  the  degree  of  Master 
of  Business  Administration. 


FACTORS  IN  MANAGEMENT  INFORMATION  SYSTEM  FAILURES 


APPROVED: 


FACTORS  IN  MANAGEMENT  INFORMATION  SYSTEM  FAILURES 


by 


ELDON  WYNN  GARRISON,  B.B.A. 


PROFESSIONAL  REPORT 

Prepared  for  B.A.  398  Under  the  Supervision  of 
Dr.  Eugene  B.  Konecci,  The  Kleberg  Professor, 
in  Partial  Fulfillment  of  the  Requirements 


For  the  Degree  of 
MASTER  OF  BUSINESS  ADMINISTRATION 


THE  UNIVERSITY  OF  TEXAS  AT  AUSTIN 
Graduate  School  of  Business 
December,  1980 


I  would  like  to  offer  my  thanks  to  several 
people  for  making  completion  of  this  report  possible. 

Dr.  Eugene  B.  Konecci's,  the  Kleberg  Professor, 
personal  support  and  cooperation  gave  impetus  and  direc¬ 
tion  to  my  efforts.  His  ability  to  cause  one  to  think  and 
plan  has  improved  not  only  my  own  goals  in  life,  but  those 
of  countless  other  students  as  well. 

Many  friends  and  fellow  students  have  offered 
continued  support  throughout  this  educational  program  and 
in  the  completion  of  this  report.  I  am  particularly 
grateful  to  Brian  Deaton.  Through  hours  of  conversation, 
he  allowed  me  to  draw  on  his  years  of  experience  in  the 
field  of  MIS. 

I  also  owe  a  note  of  appreciation  to  the  United 
States  Army  for  giving  me  this  opportunity  to  further  my 
education  under  a  fully  funded  program. 

Last,  but  most  important,  my  thanks  to  my  wife, 
Barbara,  for  putting  up  with  me  during  the  often  traumatic 
experience  of  preparing  this  report. 

E.  W.  G. 

The  University  of  Texas  at  Austin 
November  6,  1980 


TABLE  OF  CONTENTS 


Chapter  Page 

I.  INTRODUCTION  .  1 

Background  .  1 

Purpose  .  2 

Scope .  3 

II.  TECHNOLOGY .  5 

Capabilities  and  Limitations  .  6 

Faulty  Applications  . 

Resistance  to  Technological  Change  .  12 

Summary . 13 

III.  HUMAN  ASPECTS . 15 

Communications  . 

Verbal . 16 

Written . 17 

Informal  Networks  .  19 

The  Role  of  Top  Management . 20 

Developing  the  MIS . 21 

Project  Team  Concept . 22 

Leadership  Factors  .  . . 23 

Nontechnical  Roles  .  27 

The  User . 30 

Situation  Review  .  31 

Specification  of  Requirements  .  32 

Design  and  Analysis  of  Alternatives  ....  39 

Implementation  .  39 

Evaluation  43 

Summary . 43 

IV.  MONEY  AND  KNOWLEDGE . ' . 46 

Money  . . 46 

Scarcity . 46 

Need . 47 

Cost  Versus  Benefit . 48 


iv 


Chapter 


Knowledge  .  . 

The  Quest  . 

Scientific  Knowledge 

V.  SUMMARY  AND  CONCLUSION  . 
Summary  . 

Conclusions  . 

Recommendations  .... 

APPENDIX  . 

BIBLIOGRAPHY  . 


v 


LIST  OF  FIGURES 


Figure  Page 

1.  CONTINGENCY  ANALYSIS  .  35 

2.  UNCERTAINTY  WORKSHEET  .  36 

3.  INFORMATION  REQUIREMENTS  ASSURANCE  STRATEGIES  .  37 

4.  THE  CONTINGENCY  MODEL . 38 

5.  SIX  BLIND  MEN . 60 


E 


LIST  OF  ILLUSTRATIONS 


Illustration  Page 

1.  PROGRAM  STAGES . 66 

2.  STAGE  I:  PREPROGRAM  . . 67 

3.  STAGE  II:  ANALYSES . 68 

4.  CYCLE  I . 69 

5.  MIMIC2S  STAGES  I  &  II . 70 

6.  MIMIC2S  STAGES  III,  IV  &  V . 71 


vii 


CHAPTER 


I 


INTRODUCTION 


Background 

Information  plays  a  vital  role  in  the  manage¬ 
ment  of  today  s  world.  However,  there  seems  to  be  a  de¬ 
creasing  ability  to  deal  with  the  amount  of  information 
generated.  Technology  has  enabled  mankind  to  compile 
vast  data  bases;  yet,  the  systems  for  filtering,  editing, 
and  manipulating  these  data  have  not  always  proven  very 
effective  in  enhancing  the  decision-making  capabilities 
of  managers. 

Management  Information  Systems  (MIS)  are  sup¬ 
posedly  designed  to  facilitate  the  assimilation  of  infor¬ 
mation.  The  manager  can  then  selectively  use  the  informa¬ 
tion  needed  to  make  better  decisions  instead  of  being 
overwhelmed  by  an  information  overload. 

There  are  too  many  definitions  of  MIS  to 
enumerate  here.  For  purposes  of  this  report,  a  Manage¬ 
ment  Information  System  shall  be  defined  as  any  system 
which  functions  'to  capture  data  from  events  in  the  real 
world,  process  the  data  into  information  useful  to  a 
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manager,  and  transmit  the  information  to  him  in  a  timely 
and  useful  way."1  Although  computers  are  not  mentioned 
in  this  definition,  the  literature  on  MIS  almost  always 
assumes  computerized  systems.  This  will  also  be  the  case 
in  this  report. 


Purpose 

The  purpose  of  this  report  is  to  provide  an 
overview  of  current  literature  on  MIS  in  order  to  deter¬ 
mine  what  are  perceived  to  be  the  principal  causes  for 
the  failure  of  MIS.  It  is  assumed  that  most  readers  will 
have  at  least  a  slight  familiarity  with  MIS  as  a  function. 
But,  ideally,  familiarity  will  not  be  a  necessary  pre¬ 
condition  for  reading  and  utilizing  the  report. 

It  is  anticipated  as  a  result  of  this  report  that 
an  individual  given  the  responsibility  for  developing  a  MIS 
could,  even  as  a  novice  or  layman  gain  insight  into  the 
problems  and  pitfalls  that  lie  ahead.  Hopefully,  he 
would  also  realize  that  the  task  is  not  an  insurmountable 


1Gerald  M.  Hoffman,  "The  Contribution  of  Manage¬ 
ment  Science  to  Management  Information,"  Interfaces 
( TIMS ) ,  9  (November,  1978):  35, 


one,  and  that  a  precisely  delineated  approach  yields  more 
satisfactory  results  than  a  haphazard  one. 
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Scope 

In  order  to  avoid  outdated  information,  the 
liaterature  reviewed  has  been  limited  to  the  past  decade 
(1970-1980)  with  a  preponderance  of  material  from  the 
latter  half  of  the  period. 

In  cases  where  authors  gave  proposed  remedies 
for  the  ostensible  causes  of  failure,  those  remedies 
have  been  included.  It  might  be  prudent  at  this  stage 
to  point  out  that  the  causes  for  MIS  failure  reviewed 
are  mostly  the  opinions  of  authors,  since  substantiating 
data  seem  to  be  lacking. 

In  trying  to  organize  the  report  by  types  of 
failure,  the  classification  task  was  very  difficult. 
Consequently,  the  categorization  of  a  particular  cause 
of  failure  may  be  a  point  of  contention  with  the  reader. 
However,  there  seem  to  be  three  classifications  of  prob¬ 
lems  in  the  literature:  technological,  human  aspects, 
and  money  and  knowledge,  which  are  discussed  in  Chapters 
II,  III  and  IV  respectively.  Any  difficulties  in 
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classifying  problems  were  resolved  arbitrarily  on  my 
part.  The  particular  problem  seems  more  important  than 

its  relative  classification. 

The  review  of  probable  causes  of  failure  in 
MIS  is  accomplished  through  addressing  MIS  in  a  generic 
sense.  That  is,  specific  applications  and/or  equipment 
are  not  examined.  I  feel  that  specificity  was  not  of 
particular  importance  since  the  problems  apply  to  MIS 
as  a  function. 


TECHNOLOGY 


This  chapter  is  not  intended  to  delve  into  a 
discussion  of  particular  types  of  hardware  and  software 
that  are  available.1  However,  when  considering  the  fac¬ 
tors  that  affect  the  success  or  failure  of  an  MIS, 
technology  cannot  be  ignored.  In  general,  technology 
has  far  outpaced  man's  ability  to  utilize  it  and  under¬ 
stand  its  application.  The  pace  of  this  advance  is  il¬ 
lustrated  by  the  statement  of  Paul  La  Voie: 


If  progress  made  in  the  automotive  industry  had 
kept  pace  with  that  in  the  computer  industry  over 
the  past  20  years,  we  would  find  that  the  auto 
industry  today  would  be  able  to  offer  a  Rolls 
Royce  for  $2.50  with  an  EP.A  rating  of  two  million 
miles  per  gallon.2 


The  literature  generally  upholds  the  view  that 
the  technology  for  supporting  decision-making  is 


1For  a  detailed  discussion  of  the  topic  see 
John  Wood  Hester,  "Technical  Developments  in  Management 
Information  Systems"  (Professional  Report,  Graduate 
School  of  Business,  The  University  of  Texas  at  Austin, 
May  1979) . 

2”EDP  Today:  Computers  Move  into  the  Office," 
Modern  Office  Procedures.  23  (May  1979):  80. 


available.3  The  problems  lie  in  the  misunderstanding 
of  the  computer' s  capabilities  and  limitations,  faulty 
applications  of  technology,  and  resistance  to  change 
brought  about  by  this  technology. 

Capabilities  and  Limitations 

Computers  have  a  tendency  to  intimidate  people. 
The  speed  with  which  they  manipulate  data  and  the  volume 
of  output  produced  seem  to  give  computers  a  life  and  will 
of  their  own.  Often,  for  the  uneducated,  this  leads  to 
overestimation  of  capabilities  and  ascription  of  traits 
to  the  computer  that  simply  have  no  basis  in  reality. 

The  sophistication  of  the  computer  lies  in  the  incredible 
calculation  speeds  for  accomplishing  simple  tasks,  and  th 
success  in  utilizing  the  technology  embodied  in  the 
computer  is  well-defined  procedures  used  repititiously . 4 

3William  A.  Jones  III,  "The  Manager's  Role  in 
Design  of  an  Integrated  Management  Information  System-- 
A  Framework  for  Planning  and  Development"  (Professional 
Report,  Graduate  School  of  Business,  The  University  of 
Texas  at  Austin,  May  1974),  p.  8. 

4Richard  F.  Denning,  "Computing  the  Need," 
Business  Insurance.  14  (March  3,  1980):  19. 


It  is  very  difficult  to  convince  some  people 
that  the  computer  is,  in  reality,  an  overgrown  calculator 
It  does  nothing,  unless  instructed  to,  and  it  facilitates 
making  decisions  rather  than  actually  making  them.  For 
example,  attributing  intelligence  to  them  makes  computers 
appear  to  manage  systems  that  require  only  routine 
decisions.  It  must  be  emphasized  that  people,  not  com¬ 
puters,  run  businesses. 

Realistic  expectations  of  computer  capabilities 
e.g.,  preparing  information  that  enables  management  to 
make  better  decisions,  can  lead  to  successful  applica¬ 
tions,  because  the  computer  is  viewed  as  a  managerial 
tool  and  not  a  miracle  worker.  Conversely,  unreasonable 
expectations  (e.g.,  the  computer  is  able  to  manage  risk), 
lead  to  user  dissatisfaction,  because  the  results  are 
not  what  was  expected.5  These  same  unreasonable  expecta¬ 
tions  cause  systems  to  be  created  that  should  not  exist. 
This  happens  because  the  reports  generated  by  the  system 
are  of  practically  no  value  and  detract  from  management's 
prime  ac t ivities-- dec i s ion-making  and  action--upon  which 

5Leroy  G.  Farber  and  Richard  L.  Ratliff, 

"People  Problems  Behind  MIS  Failures,"  Financial  Execu- 
t ive.  43  (April  1980):  19. 


corporate  success  depends.  Excessive  records  are  window 
dressing  and  detract  from  the  efforts  and  function  of  a 
MIS.®  Estimates  of  computer  output  that  is  useless  and 
extraneous  to  any  decision-making  requirement  run  as 
high  as  50  percent.7 

If  one  accepts  the  idea  that  computers  are  not 
omnipotent,  then  one  might  ask  what  capabilities  the 
computer  could  realistically  be  expected  to  have.  The 
special  computational  characteristics  of  computers  are 
effective  in  several  areas: 

(1)  Timeliness  of  reports:  Reports  can  be 
generated  at  whatever  frequency  management 
deems  necessary.® 

(2)  Detail:  The  computer  is  particularly  adept 
at  keeping  track  of  vast  quantities  of  data 
such  as  is  necessary  in  keeping  perpetual 
inventories . 9 

®Denning,  p.  19. 

7Farber  and  Ratliff,  p.  20. 

aFarber  and  Ratliff,  p.  20. 

®Farber  and  Ratliff,  p.  20. 


(3)  Convenience:  The  computer  makes  data  more 
accessible  and  facilitates  summarization  and 
cross-referencing . 1 0 

(4)  Validation  Checks:  Reduction  of  input  errors 
can  be  accomplished  through  logic  checks. 
Errors  that  are  made  can  be  corrected  through¬ 
out  the  transaction  sequence  practically 
instantaneously. 11 

(5)  Flexibility:  The  computer  offers  flexibility 
in  the  computation  and  format  of  data  thus 
enabling  the  astute  user  to  obtain  informa¬ 
tion  that  is  relevant  to  the  decisions  that 
have  to  be  made.13  Notice,  however,  that  this 
flexibility  is  largely  dependent  on  the  user . 
The  use  of  computers  in  MIS  does  not  create 

a  need  to  teach  managers  how  to  do  business  or  utilize 
information.  It  does  create  a  need,  though,  "to  educate 
managers  to  the  extent  of  the  computer-based  MIS' 

10Farber  and  Ratliff,  p.  21. 
lxFarber  and  Ratliff,  p.  21. 

12Farber  and  Ratliff,  p.  21. 
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capabilities  so  that  the  manager  can  take  full  advantage 
of  the  new  tool.”13 

Faulty  Applications 

Many  times  MIS  systems  that  are  ineffective  to 
begin  with  are  automated  under  the  mistaken  premise  that 
automation  will  result  in  a  good  system.  Not  only  is 
this  a  cost  ineffective  approach,  but  it  only  serves  to 
speed  up  a  mess.14 

Another  misapplication  occurs  when  the  task  to 
be  performed  is  outclassed  by  the  computer  system  de¬ 
signed  to  perform  it,  or  the  computer  system  itself  is 
simply  not  suitable  for  the  task.  There  seems  to  be  a 
tendency  to  think  in  terms  of  "more  is  better"  when  deal¬ 
ing  with  electronic  support  systems.  However,  this  is 
not  necessarily  true.  One  needs  to  look  at  the  frequency 
of  execution,  size  of  the  task,  and  the  amount  of 

13Irwin  H.  Derraan,  "Do  You  'MIS'  Understand," 
Business  Horizons.  15  (October  1972):  60. 

1  4 


Denning,  p.  21. 


flexibility  required  as  a  result  of  possible  changes  in 
input  and  output  requirements.  If  the  sizes  of  the 
system  and  of  the  task  are  not  closely  matched,  then  the 
cost  of  the  technology  involved  in  that  system  can  easily 
exceed  the  benefits.15 

A  further  problem  in  applying  available  tech¬ 
nology  is  one  closely  allied  with  the  "more  is  better" 
concept.  This  problem, though,  is  the  failure  to  consider 
the  skills  and  sophistication  of  the  staff  when  implement 
ing  systems.  The  story  is  recounted  of  a  firm  implement¬ 
ing  a  sophisticated  forecasting  model  that  later  had  to 
be  abandoned,  because  the  only  person  capable  of  using 
the  model  left  the  firm.1®  The  point  is  simply  that  the 
sohpistication  of  the  system  cannot  exceed  the  sophistics 
tion  of  the  staff,  unless  the  firm  is  willing  to  invest 
time  and  money  in  educating  manager  and  staff  sc  that 
they  are  able  to  use  the  technology  and  equipment. 

Sometimes  problems  are  caused  by  a  credibility 
gap.  This  occurs  when  hardware  salesmen  give  embellished 
versions,  which  may  or  may  not  be  intentionally  mislead¬ 
ing,  of  what  their  hardware  can  deliver  in  support  of 

lsFarber  and  Ratliff,  pp .  19  and  20. 

lsFarber  and  Ratliff,  p.  20. 
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business-decision  information.  Then,  what  the  system 
actually  delivers  causes  disenchantment  on  the  part  of 
management.17  Managers  need  to  keep  in  mind  that  hard¬ 
ware  salesmen  are  compensated  for  the  number  of  units 
sold  and  not  for  the  number  of  satisfied  customers. 

Resistance  to  Technological  Change 

Resistance  to  technological  change  is  caused 
primarily  by  two  factors:  (1)  fear  of  the  computer 
itself  and  (2)  interface  problems  among  users,  systems 
designers,  and  programmers.  Recognition  of  these  prob¬ 
lems  is  needed  because  if  users  oppose  the  changes,  the 
system  will  fail,  regardless  of  its  effectiveness. 

Fear  of  the  computer  involves  the  mystique 
caused  by  the  jargon,  which  frightens  and  discourages 
many  people.  The  insecurity  caused  by  the  lack  of 
necessary  facility  in  vocabulary  heightens  fears  of  job 
displacement  or  downgrading.  This  fear  can  attain  such 
magnitude  that  sabotage  of  the  system  can  be  a  very  likely 
occurrence,  and  computer  systems  are  very  vulnerable  in 
this  aspect.18 

17Around  M.  Kneitel,  "The  Comput- A- Cator  in 
Business,"  Journal  of  Systems  Management.  27  (May  1976): 15. 

i  a 


Farber  and  Ratliff,  p.  21. 
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The  same  deficiency  in  the  specialized  vocab¬ 
ulary  of  technology  leads  to  interface  problems  among 
users,  designers,  and  programmers,  because  they  cannot 
communicate.  This  can  be  partially  overcome  by  requir¬ 
ing  users  to  play  an  active  role  in  the  planning  and 
designing  of  systems.  However,  the  user's  resistance 
may  be  so  great  as  to  cause  changes  in  either  the  system 
or  the  user  staff.  Minimizing  the  impact  of  this  can 
be  accomplished  in  part  by  maintaining  open  communica¬ 
tion  lines.  Be  honest  about  how  technological  changes 
will  affect  their  jobs  and  offer  retraining  or  assistance 
in  relocating  should  the  employee  find  the  situation 
intolerable.  These  actions  can  and  should  be  undertaken 
to  lessen  the  trauma  of  change.19 

Summary 

The  technology  for  supporting  managerial 
decisions  is  presently  at  such  a  developed  state  that 
it,  in  and  of  itself,  is  not  a  problem.  The  problem 
seems  to  be  that  the  computer  is  expected  to  make  deci¬ 
sions,  and  that  process  is  still  too  complex  for 

I  9 


Farber  and  Ratliff,  pp .  21  and  22 
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technology.  Further  aspects  of  the  problem  include 
inadequate  concern  for  matching  system  complexity  with 
staff  sophistication,  understanding  the  applications 
for  which  a  computer  is  suited,  hostility  brought  about 
by  foisting  technology  on  an  unsuspecting  and  ill- 
prepared  staff,  and  subscribing  to  the  belief  that 
"more  is  better." 

Recognition  of  the  problems  brought  about  by 
technology  can  help  alleviate  the  disruptions  somewhat. 
But  in  some  instances,  particularly  in  problems  caused  by 
resistance  to  technology,  education  seems  to  be  a  very 
viable  alternative. 


CHAPTER 


III 


HUMAN  ASPECTS 


Where  human  systems  and  technical  systems  interact, 
it  is  usually  the  case  that  our  ability  to  under¬ 
stand  and  manage  the  human  side  of  the  equation 
lags  our  ability  to  develop  the  technical  side.1 

Perhaps  the  most  significant  aspects  of  MIS 
failure  involve  the  human  resource.  It  is  difficult, 
in  fact,  to  list  any  cause  of  failure  that  does  not  have 
its  origins  in  some  kind  of  human  interface  with  the 
system.  As  the  quote  above  suggests,  our  ability  to 
deal  with  the  human  resource  is  somewhat  lagging,  and 
the  manager  must  be  cognizant  of  the  problem  areas  that 
arise  as  a  result. 


Communications 


Communications  requires  three  basic  elements: 
(1)  a  source,  (2)  a  message,  and  (3)  a  receiver  or 
destination,  which,  in  turn  becomes  the  source  of 


xMary  E.  Lippitt,  A  Behavioral  Analysis  for 
Planning  MIS  Implementation.  Management  Information 
Systems  Research  Center  Working  Paper  Series,  MISRC- 
WP-90-10  (University  of  Minnesota,  Minneapolis,  Minn., 
1979),  p.  1. 
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further  communication.  Problems  can  crop  up  at  any  point 
in  the  process  and  render  the  system  useless. 


Verbal 


As  mentioned  above,2  inadequate  verbal  skills 
cause  interface  problems  with  some  personnel,  leading 
to  difficulties  in  communications.  Also,  the  use  of 
jargon  is  often  a  factor  in  shifting  responsibility  for 
poor  performance  or  in  intimidating  less  knowledgeable 
supervisors.  Irwin  H.  Derman  refers  to  this  as  using 
"alphabet  soup"  and  gives  the  following  illustration: 


Setting:  Friday,  4  p.m. 

Manager  (angry):  "Why  were  the  payroll  checks 
late  today  ?" 

DP  (data  processing)  Manager  (apologetic): 
"Because  my  request  for  2314S  was  disapproved 
last  spring.’" 

Manager  (regrouping):  "Oh."3 


Derman  went  on  to  say: 


The  DP  Manager  could  just  as  easily  have  said  his 
Fragistan  was  on  the  fritz.  The  DP  Manager  is 
engaged  in  the  well-known  " alphabet- soup"  game; 


2See  Chapter  II,  pp. 12-13. 

3Irwin  H.  Derman,  "Do  You  'MIS'  Understand, 
Business  Horizons,  15  (October  1972):  59. 
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using  such  phrases  as  "Hasp,"  "RJE,"  "2701,"  and 
so  on.  DP  Managers  have  found  this  an  effective 
technique  for  avoiding  both  criticism  and  a  de¬ 
crease  in  next  year's  budget. 

Any  general  manager  who  receives  a  memorandum 
filled  with  computer  jargon  should  demand  an  English 
translation.  After  all,  if  a  salesman  said  he 
didn't  get  the  Jones'  contract  because  the  "moon 
was  in  the  seventh  house,"  you  would  probably  fire 
him.  On  the  other  hand,  if  he  said  that  Jones 
was  feeling  lousy  the  day  of  the  presentation, 
you  would  probably  understand.4 


Full  and  open  communications  can  help  avoid 
interface  problems  both  prior  to  and  after  the  actual 
implementation  of  a  MIS.  Any  system  that  is  cloaked  in 
secrecy  or  forced  down  the  corporate  throat  will  cause 
resistance  that  will  probably  doom  the  system  to 
failure . 5 


Written 


Oral  communications  are  a  problem,  but  so  are 
written  communications.  For  example,  a  computer  print¬ 
out  200  pages  long  does  little  to  aid  an  executive  in 
making  a  decision.  What  he  does  need  is  information  in 

4Derman ,  p .  59 . 

5William  3.  Carper,  "Human  Factors  in  MIS," 
Journal  of  Systems  Management.  28  (November  1977):  50. 
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a  format  that  is  brief  and  can  be  easily  and  quickly  assim¬ 
ilated.  To  accomplish  this,  Arnold  M.  Kneitel  offers  a 
universal  formula  for  communicators  to  consider:  (l)  Get 
the  reader's  attention  by  offering  a  well  organized  for¬ 
mat,  using  a  logotype  and  as  few  sheets  as  feasible; 

(2)  Maintain  interest  through  the  proper  use  of  language, 
sticking  with  short,  simple  words  as  much  as  is  practical; 

(3)  Facilitate  decision  making  by  underlining  key  points, 
using  captions,  computing  ratios,  making  comparisons,  and 
data  ranking;  and  (4)  Keep  in  mind  that  the  report  should 
cause  some  form  of  action.  That  is,  it  should  trigger  a 
decision  leading  to  an  action.  Whether  that  action  takes 
an  overt  or  covert  form  is  immaterial.  These  may  not 
seem  to  be  very  profound,  given  their  simplicity,  but 
sometimes  the  more  mundane  attributes  are  the  most  diffi¬ 
cult  to  achieve.  For,  as  Kneitel  notes,  "Good  communi¬ 
cation  isn't  recognized;  it  just  does  its  job."7 

I 

f 

j 

®Arnold  M.  Kneitel,  "The  Comput-A-Cator  in 
Business,"  Journal  of  Systems  Management,  27  (May  1976): 

18,  19. 

7Kneitel,  p.  18. 

r 

r 

k 

\ 

I; 

i 


■i 


19 


Informal  Networks 

When  speaking  of  communication,  attention  must 
be  drawn  to  the  existence  of  not  only  a  formal  network 
but  an  informal  one  as  well.  This  informal  network 
exists  as  a  result  of  man's  need  to  maintain  social 
contact  with  fellow  workers  and  the  resultant  social 
environment  existing  within  the  organization.  It  is 
also  supported  by  management's  perceived  need  for  "soft, 
unstructured"  information  in  making  many  decisions.  As 
a  result,  people  often  resist  giving  up  informal  or  un¬ 
official  communication  systems.  This  must  be  recognized, 
or  the  situation  may  arise  as  one  researcher  discovered, 
wherein : 


Managers  still  maintained  volumunious  hand-kept 
reports  and  Journals  after  advanced  MIS  had  been 
successfully  in  operation  for  many  months.8 


It  should  be  obvious  that  the  result  is  a  tremendous 
waste  of  resources  and  concomitant  erosion  of  the  MIS 
effort . 


301en  Clifton  Billingsley,  III,  "Some  Possible 
Behavioral  Problems  Associated  with  the  Implementation 
of  a  Total  Management  Information  System"  (Professional 
Report,  Graduate  School  of  Business,  The  University  of 
Texas  at  Austin,  December  1972),  p.  S3. 
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The  Role  of  Top  Management 

Top  management  support  for  MIS  is  a  necessary 
condition  for  its  success.  However,  many  of  them  shun 
involvement  in  any  aspect  of  MIS.  Instead,  a  critical 
function  of  MIS  effort  such  as  the  design  of  the  system 
is  delegated  to  a  lower  echelon  employee--a  systems 
analyst  or  an  assistant  controller.  That  person  must 
then  design  a  system  based  on  plans  and  assumptions 
never  fully  communicated  to  him.9  Despite  this. 


Top  management  wants  middle  management  to  react  to 
the  events  that  actually  occur,  not  to  those  that 
might  have  occurred  had  the  real  world  been  kind 
enough  to  conform  to  the  planning  assumptions.10 

It  would  seem  logical,  therefore,  that  Derman  is  correct 
in  saying  that,  "Top  management  involvement  in  the  plan¬ 
ning  process  is  a  prerequisite  for  successful  design 
and  implementation."11  This  viewpoint  is  shared  by 
Carper,  who  believes  that  many  CEOs12  only  pay  lip  service 


9Derman,  p.  56. 

10William  A.  Jones,  III,  "The  Manager’s  Role 
in  Design  of  an  Integrated  Management  Information  System-- 
A  Framework  for  Planning  and  Development  (Professional 
Report,  Graduate  School  of  Business,  The  University  of 
Texas  at  Austin,  May  1974),  p.  19. 

11Derman,  p.  57. 

12Chief  Executive  Officer. 


21 


to  MIS,  because  they  do  not  believe  computerized  informa¬ 
tion  systems  really  work.  And,  things  that  the  CEO  does 
not  support  usually  fail.13 

Not  only  is  it  important  to  have  the  support  of 
and  participation  by  top  management  in  MIS,  the  lead 
executive  in  the  information  service  department  is  pivotal 
and  should  be  held  accountable  for  the  success  or  failure 
of  the  MIS  effort.14  Furthermore,  the  chances  for  MIS 
success  are  practically  zero  if  this  executive  is  more 
than  two  levels  below  the  CEO.15 

Developing  the  MIS 

MIS,  as  does  any  project,  cycles  through 
several-  stages.  Though  the  various  stages  are  called 
by  many  names,  the  nomenclature  is  not  particularly  im¬ 
portant.  For  purposes  of  this  report  the  stages  will 
be  designated  as:  (1)  analysis  of  the  current  situation, 
(2)  determination  of  requirements  and  specifications, 

13Carper,  pp .  49  and  50. 

14John  V.  Soden,  "Understanding  MIS  Failures," 
Data  Management.  13  (July  1975):  33. 

lsPhillip  Ein-Dor  and  Eli  Segere,  "Organizational 
Context  and  the  Success  of  Management  Information  Systems," 
Management  Science.  24  (June  1978):  1074. 
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(3)  development  of  alternative  system  designs,  (4) 
analysis  of  the  alternative  designs,  (5)  choosing  of  an 
alternative  and  implementation,  and  (6)  evaluation  of 
the  system.  It  is  not  the  purpose  of  this  report  to 
enter  into  a  detailed  discussion  of  each  of  these  stages, 
but  to  discuss  relevant  factors  that  impact  on  whether 
the  end  result  will  succeed  of  fail. 

Pro.ject  Team  Concept 

In  attacking  MIS  projects,  the  development 
assignment  is  far  too  frequently  given  to  system  designers 
and  programmers.  Problems  result  because  of  this  almost 
completely  technical  orientation.  These  technical  per¬ 
sonnel  are  generally  more  concerned  with  creating  an 
efficient  system,  wherein  their  expertise  lies,  than 
with  creating  an  effective  one.  For  example,  in  the 
case  of  programmers,  they  "don’t  understand  complex 
business  functions  any  better  than  top  executives  under¬ 
stand  programming."13  Why  then  should  they  be  expected 
to  come  up  with  a  support  system  for  a  function  that  is 
not  understood  ? 


laG.  E.  Mueller,  "Blueprinting  a  Workable 
MIS,"  Administrative  Management.  39  (September  1978): 
25. 
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A  viable  approach  to  MIS  efforts  is  the  project 
team.  Unfortunately,  a  practice  in  wide  use  is  to 
assign  people  to  the  team  based  on  availability  and  im¬ 
mediate  productivity  rather  than  on  the  basis  of  know¬ 
ledge.  In  this  way,  it  is  hoped,  excessive  "overhead" 
costs  can  be  avoided.  This  should  not  be  allowed  to 
happen,  though.  "It  is  critical  to  top  quality  systems 
development  that  only  people  with  a  wide  knowledge  of 
operations  and  plans  be  assigned  to  the  MIS  team."17'18 

Leadership  Factors 

There  is  no  magic  formula  for  determining 
either  the  leadership  or  composition  of  the  project  team. 
However,  one  needs  to  be  aware  that  the  philosophy, 
political  ability,  and  managerial  skills  of  the  lead 
executive  in  the  information  services  department  will 
bear  heavily  on  the  eventual  success  or  failure  of  the 
MIS  effort,  regardless  of  whether  or  not  that  person  is 
the  project  leader.  For  that  reason,  he  is  often  referred 
to  as  the  MIS  architect.  Such  lead  executives  can  be 


17Emphasis  added. 
1 aDerraan,  p .  57 . 
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categorized  into  five  types:19 

(1)  The  "flamboyant  conceptualizer"  is  a  creative 
communicator,  strategically-oriented,  per¬ 
suasive,  and  sees  the  whole  picture.  He  wants 
vast  commitments  of  resources  in  order  to  force 
MIS  "revolution"  rather  than  "evolution,"  and 
he  attracts  bright,  motivated,  inexperienced 
young  people.  His  lack  of  specificity  in 
developing  detailed  control  measures  for  the 
MIS  effort,  coupled  with  the  magnitude  of  the 
attempted  changes,  lead  to  costly  failures 

and  abandonment  of  the  effort.  He  is  usually 
found  in  larger,  less  well-managed  companies 
where  the  opportunities  for  cost  savings  in 
clerical  areas  are  plentiful.  As  a  result, 
he  is  often  overly  optimistic  in  calculating 
ROI  when  attempting  to  justify  the  requests 
for  resource  allocations.20 

(2)  The  "benign  under- ac hiever"  takes  virtually 
no  risks.  His  primary  failure  is  missed 

19John  V.  Soden,  "Understanding  MIS  Failures," 
Data  Management,  13  (July  1975):  32. 

20 


Soden,  p.  32. 
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opportunities,  and  he  works  with  a  very  stable 
(and  uninspired)  group  of  professionals 
organized  into  a  team  that  has  weak  controls 
and  attempts  to  keep  a  low  profile  on  the 
project.  The  lack  of  crisp  performance  mea¬ 
sures  allows  him  to  hide  his  failures.  This 
individual  is  usually  found  in  mature  industries 
where  management  is  status-oriented  rather 
than  achievement-oriented.21 

(3)  The  "tyrant"  has  very  strong  budget  controls, 
and  these  are  the  only  controls  utilized.  He 
does  not  recognize  or  understand  the  benefits 
of  new  information  systems  or  new  technologies. 
He  maintains  a  stable  organization  with  turnover 
confined,  for  the  most  part,  to  talented  new 
employees  who  become  frustrated  by  the  lack  of 
opportunity . 22 

(4)  The  "efficiency  expert"  is  a  very  exceptional 

t 

individual,  because  he  recognizes  the  need  for 
strong,  well-balanced  controls.  His  primary 
focus  is  on  quantitative  measures,  and  the 

21Soden,  p .  32 . 

22Soden,  p.  32. 


26 


systems  development  effort  is  toward  opera¬ 
tional  areas  that  are  designed  to  support 
centralized  clerical  activities,  efficiency, 
and  effectiveness.  A  strong  organization  is 
maintained  with  a  concentration  of  talented 
systems  programming  individuals.  He  is  given 
an  increasing  scope  of  responsibility,  be¬ 
cause  he  is  operations-oriented,  and  he  main¬ 
tains  a  tight  rein  on  administrative  functions. 
The  activities  he  controls  serve  as  maintenance 
enhancement  activities  with  the  primary  objec¬ 
tive  of  reducing  MIS  departmental  costs.  Quick 
response  to  user  requests  is  a  benefit,  al¬ 
though  there  is  little  contribution  to  long¬ 
term  improvement  of  the  decision-making 
capabilities  within  the  company.23 

(5)  The  "fast  tracker"  combines  the  positive  at¬ 
tributes  of  both  the  "flamboyant  conceptualiz er" 
and  the  "efficiency  expert."  Needless  to  say, 
finding  this  individual  within  an  organization 
is  a  very  rare  occasion.24 

23Soden,  p .  32 . 

24Soden,  p.  32. 


It  is,  to  reiterate,  crucial  that  the  traits 


of  this  executive  be  recognized.  However,  the  skills  of 
the  project  team  leader  are  simply  those  required  of  any 
functional  manager:  planning,  organizing,  staffing, 
directing,  coordinating,  and  evaluating.25  Thus,  appoint 
ment  of  a  person  with  those  identified  skills  as  the 
team  leader  should  prove  adequate  to  the  task. 

Nontechnical  Roles 

In  addition  to  analysts  and  programmers,  there 
are  also  several  other  roles  that  need  to  be  filled  on 
the  team.  These  roles  are  also  considered  to  be  vital 
for  mission  success  and  should  be  filled  by  personnel 
with  nontechnical  backgrounds  and  perspectives. 

One  role  is  that  of  organizational  development, 
which  focuses  on  total  system  changes.  Because  MIS 
changes  such  patterns  and  expectations  of  organizational 
performance  as  the  formal  and  informal  cultures,  the 
organizational  development  function  is  to  facilitate 
adaptation  of  MIS  technology  to  the  institution's  culture 

25Eric  <J.  Eno,  "The  Administrative  Generalist 
and  MIS,"  Public  Administration  Review,  39  (September/ 
October  1979):  498. 
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This  adaptation  ranges  from  achieving  concensus  on  MIS 
parameters  at  higher  management  levels  to  gaining  ac¬ 
ceptance  for  the  project  at  working  levels.  The  ability 
to  motivate  commitment  is  the  skill  required  here,  and 
a  nontechnical  individual  is  more  likely  to  have  it  than 
would  a  computer  expert.20 

Too  often  users  are  offered  no  alternatives 
other  than  to  "take  or  leave"  a  system,  and  they  take  it 
thinking  "something  is  better  than  nothing."  Because 
of  this,  the  role  of  user  advocacy  must  be  filled.  The 
analyst  approaches  design  with  three  types  of  criteria 
in  mind:  (l)  equipment  constraints,  (2)  standards  and 
conventions  internalized  through  his  prior  work  experience, 
and  (3)  user  requirements  or  desires.  However,  he  is 
more  comfortable  with  the  first  two,  and  they,  therefore, 
get  more  attention  in  the  ultimate  design.  It  is  impera- 
t ive  that  the  user  advocate  role  be  someone  other  than 
the  principal  designer.  Otherwise,  users  will  be  in¬ 
timidated  by  technology  and,  as  a  result,  will  demonstrate 
an  unwillingness  to  control  their  own  destinies.27 


2sEno,  p.  486. 

27Eno,  pp .  486  and  487. 
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In  order  to  maintain  the  functions  of  control, 
efficiency,  and  planning,  the  data  base  must  be  indepen¬ 
dent  of  the  uses  to  which  it  is  put,  and  this  requires 
an  MIS  advocate.  He  sees  that  planned  applications  yield 
products  that  are  accessible  and  usable  by  programs  serv¬ 
ing  other  MIS  functions.  One  of  his  primary  functions 
is  to  remind  analysts  of  their  responsibility  to  the  over¬ 
all  MIS  of  the  organization.29 

One  of  the  major  causes  of  poor  systems  design 
is  the  lack  of  communication  between  the  user  and  the 
specialist.  This  unhappy  state  is  brought  about  because 
each  fears  appearing  ignorant  to  the  other.  It  would 
seem,  then,  that  bridging  this  gap  is  a  necessary  role 
to  be  fulfilled,  and  it  involves  insuring  that  the  user 
and  specialist  understand  each  other.  The  user's  needs 
must  be  clearly  spelled  out  early  in  the  project's  de¬ 
velopment,  and  he  must  understand  how  the  MIS  will  meet 
those  needs.  In  addition,  the  user  should  also  gain  in¬ 
sight  into  how  the  MIS  will  affect  his  customary  way  of 
doing  things. 29 

23Eno,  p.  487. 

29Sno,  p.  487. 
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If  it  seems  to  the  reader,  at  this  point,  that 
there  may  be  more  to  think  about  in  getting  an  MIS 
project  off  the  ground,  the  assumption  is  quite  correct. 

A  further  consideration,  previously  alluded  to  several 
times,  is  the  importance  of  the  user. 

The  User 

The  user  is  the  individual  for  whom  the  system 
is  being  designed.  It  would  then  seem  intuitively  logical 
that  he  be  included  in  the  project  from  its  inception  as 
a  member  of  the  project  team.  This  will  help  dispel 
problems  arising  from  unrealistic  expectations  of  what 
the  system  is  able  to  do.  Although  the  term  "user"  is 
used  in  the  singular,  realistically,  a  representative 
from  every  using  department  should  be  on  the  team.  In 
this  way,  open  lines  of  communication  are  maintained  be¬ 
tween  the  team  and  managers  of  the  departments  that  the 
system  will  hopefully  support. 

Users  as  team  members  also  insure  that  manage¬ 
ment  is  kept  abreast  of  both  progress  and  problems  in 
the  design  effort.  This  can  help  to  create  an  atmosphere 
of  total  involvement  of  all  management  personnel.'  How¬ 
ever,  care  must  be  taken  that  users  are  assigned  the 


correct  tasks.  They  cannot  be  expected  to  know  and  do 
detailed  work  such  as  is  performed  by  systems  analysts 
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and  programmers.30  The  importance  of  user  participation 
is  underscored  by  Lucas  in  his  statement,  "users  do  not 
understand  much  of  the  output  they  receive."31  One  way 
to  preclude  this  is  through  active  involvement  and  open 
communications  . 

Given  that  the  project  team  is  now  formed  in 
accordance  with  the  proposed  guidelines,  consideration 
will  now  be  given  to  a  cursory  review  of  the  development 
process . 

Situation  Review 

As  already  mentioned,  it  is  a  universally  ac¬ 
cepted  tenet  that  a  project  should  start  with  a  review 
of  the  current  situation.  Without  this  step  it  is  impos¬ 
sible  to  determine  if  any  need  for  a  MIS  exists.  Often 
organizations  find  themselves  in  the  unenviable  position 
of  having  automated  a  function  without  regard  for  whether 

30Jones,  pp .  44  and  45. 

31Henry  J.  Lucas,  Jr.,  Why  Information  Systems 
Fail  (New  York:  Columbia  University  Press,  1975),  p.  2. 
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a  need  existed.  In  effect,  a  system  was  designed  and 
implemented  for  "appearances  sake."  In  this  stage,  the 
purpose  needs  to  be  stated  explicitly,  and  the  present 
capabilities  and  proposed  capabilities  delineated. 

Specification  of  Requirements 

The  second  step  in  the  process  is  to  determine 
the  system  requirements.  In  doing  thi^  determination  of 
the  user's  needs  is  paramount.  Why?  As  Eno  succintly 
puts  it:  "Failure  to  try  to  support  the  user  will  likely 
result  in  failure  of  the  user  to  support  the  project."32 
Jones  puts  it  another  way:  "Specific  management  require- 
msnts  are  prescribed  as  the  framework  to  formulate  at¬ 
tainable  system  objectives."33 

Unfortunately,  the  user  specifications  for 
requirements  are  not  usually  accurately  determined  until 
the  system  has  been  tried  outj  thu^  the  system  normally 
has  to  go  through  several  iterations  before  the  user  is 
satisfied.  Specification,  then,  is  an  error  in  the  basic 
assumption  that  a  user  can  accurately  specify  his  re¬ 
quirements.  The  answer  may  lie  in  application  simulation 
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"inexpensively  creating  a  lashed-up  computer  system  that 
will  produce,  however  inefficiently,  products  to  satisfy 
the  user  needs."3,4  This  allows  the  user  to  try  it  and 
see  if  the  results  are  acceptable. 

It  is  essential  that  the  simulation  appear  as 
finally  intended  to  the  user.  The  system  continues  to 
operate  then,  with  brief  user  specifications  created, 
resulting  in  technically  correct,  efficient  programs  to 
replace  the  lash-up,  and  integrating  them  into  the  ap¬ 
plication  simulation.  This  allows  the  user  continued 
use  of  the  system,  and  insures  that  he  recognizes  the 
benefits.  Concurrently,  the  system  stays  in  touch  with 
the  user's  world  and  allows  analysts  and  programmers  to 
develop  data  systems  in  a  timely  fashion.  Hopefully, 
the  process  results  in:  (1)  user  specifications  being 
real  requirements,  (2)  benefits  that  are  actual,  not 
promised,  and  (3)  a  system  available  in  a  shorter  time 
frame . 35 

Another  procedure  for  dealing  with  the  specifics 
tion  of  requirements  is  through  the  use  of  a  contingency 

34James  W.  Frank,  "Management  Information 
Systems:  Applications  Design  by  Trial  and  Error,"  Info- 
s ystems .  26  (September  1979  ):  78. 

35 


Frank,  p.  78. 


method  for  selecting  a  requirements  assurance  strategy. 
Here  again,  the  premise  is  that  the  biggest  cause  of 
information  systems  failing  to  satisfy  user  needs  is 
incomplete  or  inaccurate  specification  of  requirements.38 

Uncertainty  is  determined  by  four  contingencies: 
(1)  project  size,  (2)  degree  of  structuredness  of  decisions 
to  be  supported,  (3)  user-task  comprehension,  and  (4) 
developer  task  proficiency.37  Their  contribution  to  un¬ 
certainty  is  depicted  in  Figure  1. 

The  next  step  is  to  measure  the  contingencies 
and  determine  the  level  of  uncertainty  with  the  aid  of 
a  worksheet  as  shown  in  Figure  2.  Then  one  must  select 
an  information  requirements  assurance  strategy  suitable 
for  the  level  of  uncertainty  observed.38  These  strategies 
are  outlined  in  Figure  3.  The  model  in  complete  form 
is  shown  in  Figure  4. 

3aJ.  D.  Nauman,  G.  Davis,  and  J .  McKeen, 
Determining  Information  Requirements:  A  Contingency 
Method  for  Selection  of  a  Requirements  Assurance  Strate 
Management  Information  Systems  Research  Center  Working 
Paper  Series,  MISRC- WF-80-102  (University  of  Minnesota, 
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CONTINGENCY  ANALYSIS 
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INFORMATION  REQUIREMENTS  ASSURANCE  STRATEGIES 
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Design  and  Analysis  of 
Alternatives 

In  the  project  stage  (where  design  alternatives 
are  being  generated),  one  must  insure  that  several  alterna¬ 
tives  are  generated  and  subsequently  analyzed.  Otherwise, 
there  is  no  assurance  that  the  system  implemented  will 
be  anywhere  near  maximum  possible  efficiency  and  effec¬ 
tiveness.  In-house  designs  also  should  not  be  the  only 
designs  considered.  Often  it  can  be  advantageous  from 
both  cost  and  time  perspectives  to  see  what  packaged 
software  is  available.  Sometimes  only  insignificant 
modifications  are  needed  in  order  to  meet  specified 
requirements . 

Implementation 

» 

Avoiding  implementation  failure  is  another 
prerequisite  for  project  success.  To  accomplish  this, 
two  complementary  courses  of  action,  in  addition  to  those 
already  described  for  specification  of  requirements,  need 
to  be  undertaken.  They  are:  (1)  expansion  of  manage¬ 
ment  support  for  the  system  and  (2)  a  training  program.39 

39Uestor  Guimaraes,  Understanding  Implementation 
Failure:  Case  Analysis  on  the  MIS/User  Interface.  Manage- 
ment  Information  Systems  Research  Center  Working  Paper 
Series,  MISRC- WP- 80- 13  (University  of  Minnesota, 
Minneapolis,  Minn.,  1980),  pp .  17-18. 
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The  issue  of  management  involvement  and  support  has  al¬ 
ready  been  addressed  and  should  not  need  further  expli¬ 
cation. 

Education  of  organizational  personnel  can  help 
in  areas  concerning  misconceptions,  such  a3  the  implemen¬ 
tation  of  a  MIS  resulting  in 


the  elimination  of  great  portions  of  lower  and 
middle  management  positions.  .  .  .  Most  authors 

suggest  an  extensive  educational  program  be  insti¬ 
tuted  in  order  to  minimize  this  fear,  but  company 
educational  programs  have  a  poor  history  of  suc¬ 
cess  and  may  be  perceived  as  an  attempt  to  ''brain¬ 
wash''  the  managers  into  submission  long  enough  for 
the  system  to  be  properly  installed;  soon  after¬ 
wards,  it  would  be  predicted,  the  axe  will  fall.40 


I  believe  that  with  an  honest  educational  attempt,  user 
involvement,  and  open  communications  throughout  the  de¬ 
velopment  process  these  erroneous  perceptions  can  be 
decreased  significantly. 

Resistance  to  implementation  is  another  area 
in  which  education  can  be  of  vital  significance.  There 
are  many  causes  for  this  resistance  most  of  which  are 
due  to  ignorance.  These  causes  of  resistance  include: 


40 


Billingsley,  p.  58. 
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(1)  A  threat  to  one's  status  or  power.  MIS  makes 
Jobs  seem  more,  or  less,  important  than  before, 
and  people  do  not  like  losing  status  to  a 
machine . 

(2)  A  threat  to  one's  economic  security.  That  is, 
fear  of  displacement  by  a  machine. 

(5)  Feelings  of  insecurity.  The  technological 
threat  is  perceived  as  a  personal  attack  by 
something  not  understood,  and  the  employee 
becomes  insecure,  frustrated,  paranoid,  with¬ 
drawn,  and  hostile. 

(4)  A  threat  to  one’s  ego.  The  MIS  is  viewed  as 
a  direct  threat,  which  the  employee  is  power¬ 
less  to  fight,  and  he  perceives  himself  as 
becoming  a  glorified  "button  pusher." 

(5)  Feelings  of  uncertainty  or  unfamiliarity. 

These  are  often  caused  by  fear  of  the  unknown. 

(5)  An  increase  in  job  complexity.  Here,  the  per¬ 
ception  is  that  only  "brains"  can  handle  the 
wo  rk . 

(7)  Changed  relationships  between  superiors  and 

subordinates.  Here,  the  junior  person  may  be¬ 


come  a  de  facto  superior  of  senior  people, 
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because  he  controls  the  type  and  flow  of  in¬ 
formation  which  the  firm  has  available  for  its 
use. 

(8)  Job  or  role  ambiguity.  This  is  caused  by  a 
loss  of  autonomy  and  control  by  middle  managers 
resulting  in  uncertainty  about  their  role  within 
the  organization. 

(9)  Job  regidity  and  time  pressures.  MIS  is  viewed 
as  the  epitome  in  programmed  operations  and 
therefore  as  invalidating  the  existing  social 
system  and  its  attendant  informality. 

(13)  Changed  interpersonal  relationships  and  work 
patterns.  MIS  is  thought  of  as  an  interloper 
destroying  the  social  and  political  structures 
of  the  work  environment.41 

The  effects  of  resistance  range  from  sabotage 
of  the  system,  or  blaming  it  for  everything  that  goes 
wrong,  by  operating  personnel,  to  avoiding  the  system  by 
ignoring  its  output  on  the  part  of  middle  and  top  manage¬ 
ment.42  All  these  causes  and  effects,  though,  are  pos¬ 
sible  candidates  for  a  reduction  in  strength  through 

41Carper,  pp .  48  and  49. 

42Carper,  p.  49. 
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educating  (or  reeducating)  personnel  impacted  by  the 
system  and  through  the  other  counter-measures  previously 
discussed  in  this  chapter. 

Evaluation  and  Feedback 

Even  after  implementation  is  successful,  the 
project  is  still  not  completed.  It  must  be  remembered 
that  the  system  is,  or  should  be,  dynamic  and  not  static. 
There  needs  to  be  periodic  evaluation  of  the  system  in 
order  to  insure  that  the  MIS  is  maintaining  its  effec¬ 
tiveness  and  efficiency.  This  evaluation  compares  the 
actual  objectives,  scope,  and  benefits  of  the  MIS  with 
the  objectives,  scopes,  and  benefits  as  determined  during 
the  design  stage.  MIS  needs  the  feedback  from  these 
evaluations  in  order  to  maintain  quality  assurance  as 
much  as  any  product  line  put  out  by  a  manufacturing 
process  does. 

Summary 

Because  of  the  tremendous  differences  in  learn¬ 
ing  ability  between  people,  the  extension  of  com¬ 
puter  utilities  could  result  in  chaos  if  informa¬ 
tion  services  are  not  socially  engineered  to  ac¬ 
commodate  the  vast  range  of  individual  differences 
while  exist  in  our  society.  If  we  are  genuinely 
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concerned  with  the  application  of  computers  in 
information  systems  and  with  social  effectiveness, 
we  must  recognize  that  advances  in  man-machine 
communications  will  be  inspired  and  consumated 
by  advances  in  man-man  communication.43 

If  the  project  team  does  not  recognize  the  interactions 
of  man  and  machines  in  the  whole  development  process, 
and  the  attendent  problems,  the  effort  is  doomed  to 
failure . 

Special  problems  have  been  examined  in  the 
areas  of  communications,  the  role  of  top  management, 
the  formulation  of  a  project  team,  and  the  development 
cycle  as  it  impacts  on  the  MIS  efforts.  The  complexities 
involved  seem  almost  insurmountable.  However,  they  must 
be  overcome  and  dealt  with  or  the  development  cycle  be¬ 
comes  one  of  enthusiasm,  incipient  doubt,  schedule 
slippage,  cost  overruns,  finger  pointing,  and  scrapping 
of  the  project.  This  results  in  an  information  system 


43Maurice  Glenn  Gardner,  "Human  Factors  Ap¬ 
plications  in  Information  Systems  Design  and  Implementa¬ 
tion"  (Professional  Report,  Graduate  School  of  Business, 
The  University  of  Texas  at  Austin,  May  1975),  p.  66. 


that  does  little  for  only  a  few.44  In  this  age  of 
scarce  resources,  such  waste  cannot,  and  should  not, 
tolerated . 


44Richard  F.  Denning,  "Computing  the  Need," 
Business  Insurance  14  (March  1980):  19. 
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I  V 

MONEY  AND  KNOWLEDGE 


There  are  other  factors,  though,  tied  closely 
to  the  human  and  technological  aspects  that  bear  strongly 
on  whether  MIS  efforts  will  succeed  or  fail.  For  pur¬ 
poses  of  this  report  those  factors  are  discussed  under 
the  nomenclature  of  money  and  knowledge . 

Money 


Scarcity 


Overall  expenditures  for  the  support  of  infor¬ 
mation  systems  average  about  1  percent  of  sales  revenue. 
Out  of  that  1  percent,  approximately  35  percent  is  used 
for  purchasing  hardware  resources.  The  rest  covers 
personnel,  supplies,  services,  and  telecommunication 
costs.1  Out  of  the  portion  alloted  for  personnel,  60 
percent  goes  for  maintenance  of  old  systems--some  as  old 

1William  M.  Taggart,  Jr.,  Information  Systems: 
An  Introduction  to  Computers  in  Organizations  ( Boston: 
Allyn  and  Bacon,  Inc .,  I960  ) ,  p"!  160 . 
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as  25  years--and  40  percent  is  applied  to  the  develop¬ 
ment  of  new  information  systems.  As  a  result,  there  is  a 
national  backlog  of  18  to  30  months  for  the  development 
of  new  information  systems  that  is  chasing  the  remaining 
40  percent  of  the  human  resource  allocated  for  this  pur¬ 
pose.2  It  should  be  evident  that  monetary  resources 
are  scarce  with  regard  to  the  MIS  effort,  and  the  use 
of  that  resource  needs  to  be  evaluated  very  carefully. 

Need 

Prior  to  committing  monetary  resources,  the 
proposed  application  should  be  examined  very  closely  for 
necessity  and  cost  effectiveness.3  Whether  the  present 
system  lends  itself  to  automation  should  be  one  of  the 
first  questions  asked.  Also,  the  effectiveness  and 
efficiency  of  the  present  system  are  issues  that  should 
be  addressed.  Many  times  it  is  less  expensive  to  perform 
tasks  manually  because  of  expense  involved  in  using  time 

2John  Diebold,  "New  Directions  in  Management," 
Info  systems .  26  (October  1979):  42. 

3Richard  F.  Denning,  "Computing  the  Need," 
Business  Insurance,  14  (March  3,  1980):  21. 
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on  the  computer.  Going  to  an  automated  MIS  should  be 
based  less  on  fashion  and  more  on  needl4 

Cost  Versus  Benefit 

On  a  monetary  basis,  the  decision  on  installing 
a  computerized  MIS  is  not  as  simple  as  it  might  appear. 

As  mentioned,  the  MIS  function  has  to  compete  with  other 
functions  in  the  organization  for  available  resources. 

The  lack  of  commitment  of  these  resources  often  leads 
to  MIS  failure.  The  difficulty  seems  to  lie  in  the  fact 
that  most  budgetary  allocations  are  made  on  the  basis  of 
cost/benefit  analysis,  and  many  MIS  benefits  cannot  be 
quantified,  e.g.,  opportunity  costs,  customer  good  will, 
risk  of  litigation,  public  image  and  the  work  environ¬ 
ment.  This  is  unfortunate,  because  the  MIS  function 
should  be  perceived  in  the  same  light  as  production, 
marketing,  and  finance.5  Another  reason  for  cost/benefit 
ratios  being  invalid  for  the  allocation  of  resources  to 

4Denning,  p.  21. 

5Phillip  Ein-Dor  and  Eli  Segev,  "Organizational 
Context  and  the  Success  of  Management  Information  Sys¬ 
tems,"  Management  Science.  24  (June  1978):  1170. 
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MIS  is  that  some  predictions  of  costs  and  benefits  simply 
do  not  materialize.  This  is  caused  by  unrealistic  ex¬ 
pectations  of  the  system,  poor  design,  internal  opposi¬ 
tion,  bad  guesses,  misinformation,  and  a  lack  of  informa¬ 
tion.  Cost  benefit  analysis  can  be  improved  through 
avoiding  these  problems  and  exhaustively  listing  all 
costs  and  benefits,  both  quantifiable  and  nonquantifiable . 
These  lists  should  then  be  scrutinized  very  closely  and 
subjected  to  periodic  analysis  and  review  for  as  long 
as  the  system  is  operational.8 

A  further  recommendation  for  improving  the 
cost/benefit  ratio  goes  back  to  the  phase  where  require¬ 
ments  are  defined  and  specified.  In  determining  re¬ 
quirements  for  the  response  time  of  the  system,  one  needs 
to  ask  if  instant  status  reports  on  data  are  necessary. 
Interactive  terminals  are  an  additional  expense  that  may 
not  be  vital  to  the  successful  functioning  of  the  system. 
One  way  of  determining  needed  response  time  is  to  keep  a 
log  of  internal  and  external  information  requests  and 

sLeroy  G.  Farber  and  Richard  L.  Ratliff, 

"People  Problems  behind  MIS  Failures,"  Financial 
Executive .  48  (April  1980):  23. 
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compare  current  answering  time  requirements  versus  those 
p  ropos  ed . 7 

Knowledge 

Monetary  considerations  include  all  the  over¬ 
head  costs  associated  with  the  development  life  cycle 
of  a  MIS  effort,  i.e.,  salaries  and  related  administra¬ 
tive  expenses  incurred  for  all  personnel  and  studies 
prior  to  on-line  availability  of  the  MIS.  Most  of  these 
preimplementation  expenses  result  from  the  quest  for 
knowledge  and  its  dissemination  to  the  organization. 

The  Quest 


The  quest  for  knowledge  begins  with  predevelop¬ 
ment  studies  during  the  review  of  the  current  situation. 
In  addition  to  reviewing  organizational  goals  and  objec¬ 
tives,  an  overview  of  the  existing  system  must  be  de¬ 
veloped  and  understood.  This  can  be  accomplished  through 
interviews  with  personnel  involved  in  the  system  and 
setting  the  system  information  and  communication  flows 

7Denning,  p.  19. 


i 


down  on  paper.  These  methods  allow  comparisons  between 
how  the  system  is  perceived  to  work  versus  how  it 
actually  works.  It  also  offers  an  opportunity  for 
determining  individual  duties  and  responsibilities; 
documented  by  interviews  and  Job  description,  or  rummary, 
sheets.  This  may  seem  to  be  of  secondary  importance, 
but  it  is  not.  Many  people,  if  asked,  cannot  delineate 
precisely  what  they  are  or  are  not  responsible  for. 

If  individuals  do  not  know  their  responsibilities,  then 
they  cannot  know  their  information  requirements.  This 
leads  to  wasted  resources  through  redundancy  and  duplica¬ 
tion  of  effort;  resources  that  the  organization  can 
ill  afford  to  be  careless  with. 

Another  piece  of  knowledge  needing  to  be 
developed  in  the  initial  study  period  is  a  summary  of 
client  and  customer  opportunities/problems.  Development 
of  MIS  will  always  have  some  impact  on  customers  and 
clients,  and,  if  one  is  unaware  of  the  external  environ¬ 
ment,  opportunities  for  improved  service  cm  easily  be 
overlooked.  This  would  be  imprudent  because  any  improve¬ 
ment  in  an  organization  should  have  the  ultimate  goal 
of  offering  improved  products  and/or  service  to  those  who 
provide  the  organization's  reason  for  existing. 
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Resource  estimates  also  need  to  be  calculated 
and  set  down  in  writing.  This  estimate  statement  would 
include  personnel  resources  for  users,  analysts,  and 
programmers  and  requirements  for  hardware  resources 
such  as  processing  units,  peripheral  devices,  and  soft¬ 
ware  . 

The  generation  of  knowledge  occurs  on  a  con¬ 
tinuing  basis  throughout  the  development  process.  Some 
further  examples  of  the  documentation  that  results  are: 

(1)  Situation  review:  Financial  statements, 
organizational  charts,  existing  report  for¬ 
mats,  Data  Name  Dictionary  review,  existing 
system  flow  diagrams,  and  existing  applica¬ 
tion  flow  diagrams. 

(2)  Requirements  identification  and  specifications: 
Interview  records,  interview  problem  summary, 
general  requirements  statement,  proposed  sys¬ 
tem  flow  diagrams,  proposed  application  flow 
descriptions,  proposed  report  formats,  and 
additions  to  the  Data  Name  Dictionary. 

(3)  Physical  design:  Application  flow  diagrams 
and  general  specifications. 

(4)  Program  preparation:  General  program  descrip¬ 
tion,  hierarchy  diagrams,  program  flow  charts, 
and  decision  tables. 


(5)  Procedure  preparation:  User  manual,  applica¬ 
tion  control  chart,  manual  procedures,  and 
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operation  run  procedures. 

(6)  System  conversion:  Application  test  plan, 
data  base/file  initialization  plan,  and 
training  guides.8 

Development  of  knowledge,  though,  is  not  the 
only  task  that  must  be  accomplished.  The  deleterious 
effects  of  inadequate  knowledge  on  the  part  of  organiza¬ 
tional  personnel  upon  whom  it  will  be  incumbent  to 
interface  with  the  MIS  has  already  been  discussed.  In 
order  to  minimize  resistance  to  change  and  disruption 
of  the  social  environment,  personnel  needing  additional 
training  and  education  to  bring  them  up  to  "speed”  must 
be  identified.  The  most  technologically  perfect  MIS 
is  useless  if  those  it  was  designed  to  support  lack  the 
necessary  skills  to  achieve  interface  with  the  system. 

Scientific  Knowledge 

As  pointed  out  at  the  beginning  of  this  report, 
the  causes  of  MIS  failure,  as  outlined  herein,  are 

8Taggert,  pp .  385,  423. 
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largely  the  opinions  of  authors  recognized  as  having  ex¬ 
tensive  experience  in  the  MIS  field.  Unfortunate  though 
it  may  be,  there  does  not  seem  to  have  been  extensive  re¬ 
search  to  provide  empirical  data  for  validation  of  these 
opinions.  At  least  most  of  the  literature  reviewed  did 
not  offer  supporting  data. 

Although  many  of  the  "causes"  for  MIS  failure 
seem  to  make  sense,  it  would  seem  that  a  logical  course 
of  action  would  be  to  try  and  increase  knowledge  through 
empirical  research,  rather  than  to  continue  speculating 
on  the  subject.  The  contention  is  not  being  made  that 
no  hard  research  has  been  conducted;  only  that  it  is  not 
sufficient.  This  is  an  enigma,  given  that  so  much  ac¬ 
tivity  is  taking  place  in  the  development  of  MIS  that 
surely  a  fertile  field  of  study  is  available. 

Monetary  resources  allocated  for  the  develop¬ 
ment  and  continuation  of  MIS  functions  are  relatively 
scarce.  As  a  result,  very  careful  planning  needs  to  be 
done  so  that  resources  are  not  squandered. 

Developing  and  implementing  a  major  MIS  effort 
can  take  several  years  to  accomplish.  A  great  deal  of 
knowledge  is  generated  in  the  process,  but  it  is  not 
free.  When  estimating  the  time  it  will  take  for  the  MIS 


55 

effort,  one  should  allow  a  hefty  fudge  faction  in  attempt¬ 
ing  to  quantify  the  cost  of  this  knowledge.  Through  care¬ 
ful,  astute  planning  and  analysis  the  nasty  surprises  of 
cost  overruns  and  deficient  systems  caused  by  inadequate 
knowledge  can  be  avoided. 


CHAPTER 


V 


SUMMARY  AND  CONCLUSIONS 

Summary 

This  report  has  attempted  to  focus  on  four 
areas  where  particular  care  must  be  exercised  in  order 
to  enhance  the  chances  for  success  in  Management  Informa¬ 
tion  System  efforts.  The  areas  discussed  were:  (1)  tech¬ 
nology,  (2)  human  aspects,  (3)  money,  and  (4)  knowledge. 

The  technological  problems  do  not  lie  in  the 
inability  to  support  data  processing  tasks.  Rather,  the 
problem  is  in  personification  of  the  computer  and  the 
lack  of  concern  for  matching  the  sophistication  of  the 
technology  used  with  the  sophistication  of  those  ex¬ 
pected  to  use  it.  Coupled  with  unrealistic  expecta¬ 
tions  of  computerized  systems,  this  lack  of  prudent  ap¬ 
plications  has  led  to  a  false  picture,  wherein  technology 
is  depicted  as  the  culprit  in  MIS  failure. 

Man/machine  interfaces  seem  to  cause,  either 
directly  or  indirectly,  a  fair  portion  of  the  problems 
encountered  in  developing  MIS.  These  problems  include: 
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-Resistance  to  technology) 

-Inadequate  communication. 

-Lack  of  education  as  to  the  effects  of  technological 
changes  on  the  work  environment. 

The  importance  of  having  the  support  and  in¬ 
volvement  of  top  management  was  discussed,  and  a  method 
for  dealing  with  MIS  development  efforts  was  delineated, 
i.e.,  the  project  team  concept.  Composition  of  the  team 
is  another  critical  factor  that  must  be  weighed  very 
carefully.  Relegating  the  development  task  to  those 
with  only  technical  qualifications  can  be  disastrous. 

Many  different  roles  and  responsibilities  have  to  be 
assigned  on  the  team  so  that  a  MIS  is  developed  that 
will  be  not  only  function  in  theory,  but  in  reality  as 
well . 

The  costing  of  MIS  efforts  is  another  area 
that  often  results  in  unsatisfactory  results.  Cost/ 
benefit  analysis  needs  to  be  conducted  very  carefully 
and  should  include  as  many  costs  and  benefits  that-  are 
normally  thought  of  as  nonquantif iable  as  is  possible. 

Resources  have  to  be  allocated  from  an  avail¬ 
able  base  that  has  demands  placed  on  it  from  many  direc¬ 
tions.  Thus,  realistic  demands  and  needs  must  be  de¬ 
veloped  in  order  to  achieve  efficiency  and  effectiveness 


in  the  use  of  those  resources. 
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Vast  amounts  of  knowledge  must  be  generated 
in  the  development  effort.  Developing  this  knowledge 
is  not  only  time  consuming  but  costly  as  well.  However, 
without  proper  documentation  of  the  existing  system, 
the  proposed  system,  courses  of  action  for  implementa¬ 
tion,  and  evaluation,  misdirection  and  chaos  is  often 
the  result.  Also,  the  organization  must  be  supplied 
with  the  knowledge  that  it  needs  for  acceptance  and 
utilization  of  the  system. 

Knowledge  is  also  an  area  in  which  the 
scientific  community  needs  to  expend  more  effort.  One 
can  write  opinions,  based  in  theory,  on  MIS  failure, 
but  I  believe  that  without  concurrent  presentation  of 
valid,  empirical  data  to  support  those  opinions  they, 
more  often  than  not,  fall  on  deaf  ears.  This  should 
not  have  to  happen  .  The  magnitude  and  scope  of 
activities  in  the  development  of  MIS  should  offer  a 
fertile  field  for  the  researcher  wanting  to  add  weight 
to  his  opinions. 


Conclusions 

The  MIS  development  effort  is  a  very  complicated. 


time-consuming  task.  Recognition  of  the  problems  that 
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can  negate  the  effort  is  imperative.  Some  development 
processes  take  several  years,  and  many  are  scrapped  with¬ 
out  being  brought  to  fruition,  with  the  accompanying 
waste  of  resources  and  sense  of  despair  on  the  part  of 
those  involved. 

I  believe  that  many  of  the  problems  involved 
in  MIS  development  are  caused  by:  (1)  a  lack  of  aware¬ 
ness  of  the  many  factors  that  contribute  to  MIS  failure, 

(2)  a  lack  of  direction  in  how  to  take  the  project  from 
inception  to  conclusion,  and  (3)  a  lack  of  detail  in 
assessing  what  the  current  situation  is,  what  the 
desired  situation  is,  and  the  resources  and  constraints 
for  attaining  the  desired  state  of  affairs. 

There  is  an  old  tale,  depicted  in  Figure  5,  in  | 

which  six  blind,  though  astute,  men  come  upon  an  elephant.  i 

Each  is  asked  to  describe  what  the  object  is  that  they  ] 

j 

have  encountered.  The  first  man,  feeling  the  side,  thinks  ] 

it  is  a  wall.  The  remaining  five  men  compare  the  tusk 

to  a  spear,  the  trunk  to  a  snake,  the  leg  to  a  tree,  the 

ear  to  a  fan,  and  the  tail  to  a  rope.  Much  the  same  , 

happens  in  MIS  development  if  an  overall  perspective  is 

not  maintained.  Knowledgeable  leadership,  capable  of 

viewing  the  whole  system,  is  needed  so  that  one  part  of 
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FIGURE  5 
SIX  BLIND  MEN 
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the  system  is  not  taken  out  of  context  and  lavished  with 
attention  to  the  detriment  of  the  remaining  components 
of  the  system. 

The  only  way  one  can  keep  track  of  and  accomp¬ 
lish  the  myriad  tasks  and  innumerable  details  involved 
in  MIS  development  is  to  have  a  methodology  that  will 
provide  an  adequate  framework  for  planning  and  analysis 
through  all  of  the  stages  of  development  from  preproposal 
studies  to  implementation  and  evaluation.  Otherwise, 
one  will  become  bogged  in  a  morass  of  confusing  details, 
invalid  plans  and  assumptions,  inadequate  and  wasted 
resources,  and  ultimate  failure  of  the  project. 

Recommendations 

In  order  to  achieve  direction,  maintain  con¬ 
sistency  in  purpose,  develop  sufficient  analytic  docu¬ 
mentation,  and  provide  for  a  well  balanced,  integrated 
effort,  I  would  recommend  a  model  be  used  to  carry  out 
the  MIS  effort . 

Though  there  are  probably  other  models  avail¬ 
able,  I  have  yet  to  see  any  as  all-inclusive  as  the 
Management  Integrated  Model  Information,  Capital  and 
Control  System,  or  MIMIC2S  as  it  is  usually  referred 
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to.1  This  model  was  formulated  over  several  years  by 
Dr.  Eugene  B.  Konecci,  the  Kleberg  Professor  in  the 
Graduate  School  of  Business  at  the  University  of  Texas 
at  Austin.  Dr.  Konecci  evolved  this  model  based  on  his 
many  years  experience  as  a  management  practitioner  in 
both  the  public  service  and  business  sectors.  Selected 
illustrations  are  shown  in  the  Appendix  to  demonstrate  the 
level  of  detail  and  sequencing  of  effort  induced  by  the 
model . 

The  model  is  very  flexible  in  its  application. 
It  can  be  used  in  project  planning,  product  development, 
starting  new  businesses,  or  any  other  application  where 
detailed  planning  and  analysis  are  essential  components. 
And,  a  major  MIS  project  is  one  of  the  most  demanding 
of  projects,  in  its  complexity,  that  one  can  attempt. 

The  model  has  five  stages  which  move  one 
through  an  iterative  refining  process  for  detailed  and 
systematic  analysis  of  complex  problems  or  projects. 

It  is  very  capable  of  taking  one  all  the  way  from 
preproposal  studies  to  implementation  and  evaluation  of 

1For  a  detailed  explanation  and  application  of 
the  MIMICaS  Model,  I  would  recommend  Management  In¬ 
tegrated  Model:  MIMICgS  ( Wm .  C.  Brown  Company,  Dubuque, 
Iowa,  1980),  written  by  Dr.  Konecci. 


the  project.  The  methodology  allows  identification  of 
goals  and  objectives,  levels  of  knowledge,  the  state  of 
technology,  resources  and  constraints,  and  the  individual 
subsystems  involved.  Tradeoffs  are  also  identified 
between  what  would  be  ideal  and  what  can  be  reasonably 
expected . 

As  stated  in  this  report,  a  broad  perspective 
is  needed  to  supervise  MIS  development  projects.  For 
the  novice,  or  layman,  placed  in  the  position  of  being 
responsible  for  MIS  efforts,  or  even  for  those  adept  in 
the  field,  the  MIMIC2S  model  offers  a  powerful  tool  for 
successful  accomplishment  of  the  task. 
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The  illustrations  in  this  appendix  are  included 

so  that  a  reader  can  see  the  logical  progression  of  the 
2 

MIMIC  S  model  and  the  documentation  that  can  be  generated 
through  iterations  of  each  stage  and  cycle.  The  flexi¬ 
bility  of  the  model  allows  one  to  develop  the  level  of 
planning  and  documentation  applicable  to  any  size  proj¬ 
ect.  The  level  of  detail  is  a  management  decision,  but 
the  model  can  easily  handle  any  range  from  very  general 
to  highly  specific. 


ILLUSTRATION  2 
STAGE  I:  PREPROGRAM 
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SOURCE:  Eugene  B.  Konecci,  Management  Integrated  Model :  MIMIC2S 
(Dubuque,  Iowa:  William  C.  Brown  Company,  1980),  p.  M. 


ILLUSTRATION  6 
MIMIC2S  STAGES  III,  IV  &  V 
Implementation  Phase 
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1975.  At  the  same  time,  he  received  a  commission  in  the 
United  States  Army  and  a  fellowship  from  the  United 
States  Army  to  do  two  years  of  graduate  studies.  After 
serving  with  a  combat  armor  battalion  in  Germany  for 
three  years,  he  returned  to  the  United  States  and  enter¬ 
ed  the  Graduate  School  of  Business  of  The  University  of 
Texas  at  Austin  in  January,  1979.  After  graduation  in 
December,  1980,  Captain  Garrison  will  be  assigned  to  Fort 
Knox,  Kentucky. 

Permanent  address:  5111  Old  Lufkin  Road 

Nacogdoches,  Texas  75961 


